1. Field of the Invention
This invention relates to network computing, and more particularly to failover for clients in clustered server environments.
2. Description of the Related Art
RMI (Remote Method Invocation) is a way that a programmer, using the Java programming language and development environment, can write object-oriented programming in which objects on different computers can interact in a distributed network. RMI is the Java version of what is generally known as a remote procedure call (RPC), but with the ability to pass one or more objects along with the request. The object can include information that will change the service that is performed in the remote computer. The object parameter-passing mechanism may be referred to as object serialization. An RMI request is a request to invoke the method of a remote object. The request has the same syntax as a request to invoke an object method in the same (local) computer. In general, RMI is designed to preserve the object model and its advantages across a network.
RMI is implemented as three layers:                A stub (proxy) program in the client side of the client/server relationship, and a corresponding skeleton at the server end. The stub appears to the calling program to be the program being called for a service.        A Remote Reference Layer that can behave differently depending on the parameters passed by the calling program. For example, this layer can determine whether the request is to call a single remote service or multiple remote programs as in a multicast.        A Transport Connection Layer, which sets up and manages the request.        
A single request travels down through the layers on one computer and up through the layers at the other end.
IIOP (Internet Inter-ORB Protocol) is a protocol that makes it possible for distributed programs written in different programming languages to communicate over the Internet. IIOP is a critical part of a strategic industry standard, the Common Object Request Broker Architecture (CORBA). CORBA is an architecture and specification for creating, distributing, and managing distributed program objects in a network. CORBA allows programs at different locations and developed by different vendors to communicate in a network through an “interface broker.”
An essential concept in CORBA is the Object Request Broker (ORB). An Object Request Broker (ORB) acts as a “broker” between a client request for a service from a distributed object or component and the completion of that request. ORB support in a network of clients and servers on different computers means that a client program (which may itself be an object) can request services from a server program or object without having to understand where the server is in a distributed network or what the interface to the server program looks like. Using ORBs, components can find out about each other and exchange interface information as they are running. To make requests or return replies between the ORBs, programs use the General Inter-ORB Protocol (GIOP) and, for the Internet, Internet Inter-ORB Protocol (IIOP). IIOP maps GIOP requests and replies to the Internet's Transmission Control Protocol (TCP) layer in each computer. Using CORBA's IIOP and related protocols, a company can implement programs that will be able to communicate with their own or other company's existing or future programs wherever they are located and without having to understand anything about the program other than its service and a name.
CORBA and IIOP assume the client/server model of computing in which a client program makes requests and a server program waits to receive requests from clients. When writing a program, an interface is used called the General Inter-ORB Protocol (GIOP). The GIOP is implemented in specialized mappings for one or more network transport layers. An important specialized mapping of GIOP is IIOP, which passes requests or receives replies through the Internet's transport layer using the Transmission Control Protocol (TCP). Other possible transport layers include IBM's Systems Network Architecture (SNA) and Novell's IPX.
An object adapter is a sub component in ORB that connects a request using an object reference with the proper code to service that request. The Portable Object Adapter, or POA, is a particular type of object adapter that is defined by the CORBA specification. A POA object manages the implementation of a collection of objects. The POA supports a name space for the objects, which are identified by Object IDs. A POA also provides a name space for POAs. A POA is created as a child of an existing POA, which forms a hierarchy starting with the root POA.
POAs may be transient or persistent. A Persistent Portable Object Adaptor (Persistent POA) is a POA that may be used to guarantee that the same CORBA ID is generated each time an object is activated.
The corbaloc URL (Universal Resource Locator) scheme provides “stringified” object references for obtaining or exchanging IORs (Interoperable References). The corbaloc URL scheme provides URLs that are familiar to people and similar to FTP and HTTP URLs.
CSIv2 (Common Secure Interoperability Version 2) is a specification that provides security enhancements to the CORBA infrastructure. CSIv2 defines the Security Attribute Service (SAS) that enables interoperable authentication, delegation, and privileges.
CosNaming is a CORBA Naming Service Implementation that provides the naming service for the Java Interface Definition Language (IDL).
Java Interface Definition Language (IDL) adds CORBA (Common Object Request Broker Architecture) capability to the Java platform, providing standards-based interoperability and connectivity. Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP (Internet Inter-ORB Protocol). Java IDL technology may be used by CORBA programmers who want to program in the Java programming language based on interfaces defined in CORBA Interface Definition Language (IDL). This is “business as usual” CORBA programming, supporting Java technology in a similar way as other languages such as C++ or COBOL.
Naming and directory services play a vital role in networks such as intranets and the Internet by providing network-wide sharing of a variety of information about users, machines, networks, services, and applications. The Java Naming and Directory Interface (JNDI) is a part of the Java platform that provides applications with a unified interface (API) to multiple naming and directory services. JNDI may be used to build powerful and portable directory-enabled applications. JNDI works in concert with other technologies in the Java 2 Platform, Enterprise Edition (J2EE) to organize and locate components in a distributed computing environment. Using JNDI, applications based on Java technology can store and retrieve named Java objects of any type. In addition, JNDI provides methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes.
The JNDI Service Provider Interface (SPI) provides an interface through which developers can write naming and directory service providers and make them available so that the corresponding services are accessible from applications that use the JNDI API. In this context, a service provider may be defined as a set of modules that together satisfy JNDI API requests. In addition, because JNDI allows the use of names that span multiple namespaces, one service provider implementation may need to interact with another in order to complete an operation. The SPI provides methods that allow different provider implementations to cooperate to complete client JNDI operations.
SSL (Secure Sockets Layer) is a security protocol that provides privacy over the Internet. The protocol allows client-server applications to communicate in a way that cannot be eavesdropped or tampered with. Using SSL, servers are always authenticated and clients are optionally authenticated.
PICurrent (Portable Interceptors Current) is a slot table, the slots of which are used by services to transfer their context data between their context and the request's or reply's service context. Each service that wishes to use PICurrent reserves a slot or slots at initialization time and uses those slots during the processing of requests and replies.
A container is an entity that provides life cycle management, security, deployment, and runtime services to components. A component is an application-level software unit supported by a container. J2EE components include development and deployment units in the EJB tier and Web tier. The components may include EJBs (Enterprise JavaBeans), JSPs (JavaServer Pages) and Servlets. Containers provide support for the components, providing for reliable and standardized component-specific services. Each type of container (e.g., EJB, web, JSP (JavaServer Pages), servlet, applet, and application client) provides component-specific services. An Application Client Container (ACC) is a container that supports application client components.
A DTD (Document Type Definition) is a description of the structure and properties of a class of XML files.
Enterprise JavaBeans (EJB) is an architecture for setting up program components, written in the Java programming language, that run in the server parts of a computer network that uses the client/server model. Enterprise JavaBeans is built on the JavaBeans technology for distributing program components (which are called Beans) to clients in a network. Enterprise JavaBeans offers enterprises the advantage of being able to control change at the server rather than having to update each individual computer with a client whenever a new program component is changed or added. EJB components have the advantage of being reusable in multiple applications. To deploy an EJB Bean or component, it must be part of a specific application, which is called a container.
Web program components of J2EE are generally known as servlets (“little” server programs). The application or container that runs the servlets is sometimes called an application server. A typical use of servlets is to replace Web programs that use the common gateway interface (CGI) and a Practical Extraction and Reporting Language (PERL) script. Another general use is to provide an interface between Web users and a legacy mainframe application. In Enterprise JavaBeans, there are two types of beans: session beans and entity beans. An entity bean is described as one that, unlike a session bean, has persistence and can retain its original behavior or state.
The EJB architecture is a server-side technology for developing and deploying components containing the business logic to enterprise distributed applications. EJB components are scalable, transactional and multi-user secure. The EJB specification describes a runtime environment explaining how an EJB should be developed, deployed and used. The runtime environment is the EJB server, which provides access to EJB using an execution environment with transactional service, distribution mechanisms, persistence management and security. The specification allows users to create EJB applications, freeing them from these low-level system details.
EJB uses transactions to ensure that only consistent states take place despite clients' concurrent access and failures. However, if the EJB server crashes, the service will be unavailable to clients because the object reference is invalid and the state cannot be accessed. Transaction properties (e.g., atomicity, consistency, isolation and durability) are insufficient to provide a highly available service.
Conventional application servers may be unable to work directly with CORBA applications such as rich clients because the application servers do not directly support CORBA objects. Objects created on containers of the application servers are not CORBA objects but RMI objects.